"Thorsten Froehlich" wrote:
> After looking closer at what you are doing
> (multiplication by 100000  to see more digits
> right of the comma)

Look, when I don't multiply with 1000000 and run the code, the value Test2
evaluates to 1 in all the frames. But when I multiply with 1000000, it
evaluates to 0 in frame 36 and the following ones. So I had to multiply with
1000000 to prove my point, which was that the changes in precision errors
from frame to frame could ultimately lead an expression to evaluate to
different results in different frames.

Now, having looked closer at my code, why would you say that I was just
multiplying with 1000000 to show the digits in a different way???

> and your precision arguments and way of testing it, I
> conclude you are probably misunderstanding the meaning
> of "precision of floating-point numbers".

Why?

> See, what you are effectively doing is tricking the
> display to show 19 digits.

As mentioned, it had nothing to do with showing the digits in a specific
way. The evaluation of the values Test1 and Test2 is what's interesting. And
these were dependent on that multiplication I did.

> I guess you assume "precision" refer to the part right of
> the comma.

No. I know that floating points are exponentially based, and I know they
have precision limited to about 16 digits of precision in base 10. But in my
code the multiplication with 1000000 made a difference, as I have explained,
and which you can test on your own.

> So, what you are displaying in your example is in fact
> exceeding (!!!) the available precision that is
> mathematically possible at some point.  I hope this
> explains a bit better why you cannot expect never
> changing values - they will nearly always change in a
> not mathematically exact way after applying even a
> single operation to them.

I can and will expect the constant values such as initial_clock to stay
completely the same from frame to frame. Maybe you didn't grasp the point I
wanted to show in my code, but there are two parallel set of calculations
going on. One based on the initial_clock value provided by POV-Ray, and the
other based on the initial clock formulae you provided, which is based
partly on the ever-changing clock variable.

Value1 and Test1 are derived from the initial_clock value from POV-Ray while
Value2 and Test2 are derived from your initial clock formulae. As the debug
steam shows when you run the code, Value1 and Test1 are *exactly* the same
from frame to frame, while Value2 and Test2 changes from frame to frame.
This is why I don't like your formulae and prefers an initial_clock value
given directly by POV-Ray.

Now, I know that the values derived from POV-Ray's initial_clock keyword are
just as inaccurate, but that's not the point. The point is that the value
doesn't change from frame to frame, because constants that change from frame
to frame would be a hell to debug for scene builders and macro coders.

Again, I'm still curious to hear why it's so important for you to drop the
initial_clock and final_clock keywords, when obviously, it would make things
more difficult for the users.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:  http://rsj.mobilixnet.dk (updated Feb 16)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Ring:  http://webring.povray.co.uk

Post a reply to this message